Bitmapped text and graphics applications are now commonplace. Such applications which provide for "windowing" are also available. "Windowing" is a technique whereby a visual display screen at a computer or terminal is partitioned into distinct, independent areas (windows), each generally being associated with a separately executing application program. One window is usually designated as the active windows into which data might be entered by a user, for example, while other windows may be temporarily idle or engaged in other functions, such as outputting to a printer.
Typically, windows may be located anywhere on a screen, as desired by a user. Thus, several windows can be simultaneously present on the screen with various portions of some or all of the windows, except the active window, overlapping on the screen. The active window is traditionally fully exposed to the view of the user. Alternatively, windows might be arranged to be nonoverlapping (tiled).
One example of a windowing environment is the X Window system distributed by MIT. X Window defines the protocols and provides the software routines for message communications between system programs that accept user screen inputs, from a mouse for example, and an underlying application program. Some windowing environments also establish the look and feel of the user interface to applications. An example of this type of environment is the Presentation Manager marketed by IBM. Other environments, of which X Window is an example, merely establish the underlying windowing communications environment and leave the establishment of the user interface look and feel to other system programs. The OPEN LOOK (TM) Graphical User Interface (GUI) System, marketed by AT&T for its UNIX (R) operating system, is an example of the latter. In the OPEN LOOK GUI, a separate system program that defines the interface look and feel is layered onto the X Window software.
In most windowing environments, the user interface to applications programs is characterized by screen objects that communicate information to the user and allow user input to control the operations of the application program associated with the window. A set of menu buttons is one example of such an interface. The use of icons, such as trash cans, is another. In typical windowing environments such as the X windowing system, each of these objects is also associated with a separate window. Some portions of the industry have given such types of screen objects the name "widgets" and we adopt that nomenclature here for purposes of discussion. In other words, a screen object itself is a widget corresponding to an underlying application data structure; associated with the screen object is a window, which may be managed by a system window manager. In such a case, communications between the window manager and an application program is by means of messages describing user window operations or desired window outputs. As an example, suppose that an application program, such as a database manager, is associated with an active window 100 as shown in FIG. 1. The program may display a collection of menu buttons, such as shown at 104, 106, 108 and 110. These items are called buttons because the user typically selects one by pointing to it and clicking, as with the use of a mouse or other input device. When a user selects a button, the windowing environment creates a message describing the screen operation and sends it to the application program. The application, in turn, takes some appropriate action.
The menu buttons are contained within a box 102 which may or may not be visible in all cases. Box 102 is of a class which is associated with a container widget; that is, the box contains other windows which, in turn, are associated with other widgets. The boxes 100 and 102 are also windows. The box 100 will have associated with it attributes, such as a background color and a foreground color. If the box 100 is visible, it will also be associated with a pleasing and distinctive background color, etc. The menu buttons, such as 102, also have associated attributes such as background colors.
As discussed above, in the X Window system, it is intended that each screen object such as 100 through 110 are associated with separate widgets. It is up to the application program associated with the widgets first to create these widgets before they can be used through appropriate X Window system calls, and each widget carries with it a block of memory in which is stored essential information about the widget. Actually, the memory required for each widget is divided into two blocks, one block associated with a window server, the portion of the windowing environment that creates and transmits the window messages to applications and that updates the contents of a window on the screen in response to messages from an application, and a second block associated with the client, the application program. each block is typically 150 to 300 or more bytes. The number of created widgets at any given time in a system can be quite large (typically, in the hundreds). Therefore, the amount of internal memory required just to store the required widget data can be large. To reduce this memory burden, Digital Equipment Co. recently introduced the notion of "gadgets".
A gadget is similar to a widget, except that a gadget is not associated with its own window. Rather, one or more gadgets may be associated with a single window, which in turn is associated with a container widget. Thus, in FIG. 1, the menu buttons 104, 106, 108 and 110 could be implemented as gadgets contained within container widget 102. This shifts the burden of managing screen operations, i.e. button selections, that occur inside the window 102 to the application program associated with the window. For example, if a user operates menu button 104, the windowing system creates a message that an action has occurred at coordinates so-and-so within the widget 102 and transmits the message to the application. The meaning of the screen selection that occurred at coordinates so-and-so within the containing window must be decoded and administered by the application program, whereas this function is normally provided by the X Window system.
The use of gadgets has the potential to reduce dramatically the amount of memory that is required to store the attributes associated with widgets. This is so because each gadget is not associated with its own window, thereby eliminating the need to allocate memory for widgets that would otherwise be associated with the windows. Nevertheless, the amount of such memory required, even with gadgets, can be large because only memory associated with the window side server and not the application side (the widget side) has been saved.